The code for application programs is frequently separated into a layer for user interaction (a set of “views” or user interfaces (UIs)) and a layer for implementing the internal application logic and data management (often realized through a set of “models”). The user interface typically includes menu items and other UI elements that invoke functionality implemented on the models.
Typically, a graphic designer designs the look of the user interface while a developer writes the code that implements the user interface and/or the underlying model. Graphic design and software development are two very different disciplines and it is frequently difficult for designers and developers to work together productively. Typically, a designer uses graphics tools such as Adobe® Photoshop® and Adobe® Illustrator® to create a mock up of a user interface (UI) and then a developer re-implements the UI in code. The original graphic design elements are typically not re-used in the final implementation and sometimes, parts of the design are lost in the process because the developer either cannot easily recreate the design in code or does not fully understand the design. If the design is modified, the designer may be required to redraw the UI and the developer may have to rewrite parts of the code to match the design. In short, the process is clumsy.
Another problem encountered when architecting such an application is how to expose functionality (commands) and how to map or bind that functionality to elements in the UI. For example, a text processing application may expose functionality for cutting selected text. This functionality may be exposed as a “command” (e.g., the document exposes a way to invoke a “cut” command). Program code is required to make the connection between what happens on the UI and what happens to the underlying data, that is, to define how the command binds to the menu item.
Traditionally, event handlers or command routing was employed to perform this task. Event handlers provide a direct way to bind code and UI elements. A UI element may expose an event declaration (e.g., “Click” on a menu item) and the model may implement a method (e.g., an event handler) that matches the signature of the event declaration. However, this mechanism is not very flexible. Changes in the active data model (e.g., the active document in the above example) or the command state (e.g., the “cut” command becomes inactive or disabled) typically requires additional code to be written by a developer to connect and disconnect event handlers and to update the state of the user interface.
Advanced applications that require flexibility in command handling typically assign an identifier (ID) for each command associated with a UI element. Such systems usually have a central service (sometimes called a command manager) that maps a command ID to the currently active implementation of the command. The command manager handles a set of active command targets (i.e., a set of models that expose commands). To execute a command, an identifier is sent from the UI to the command manager and the command manager finds the command target that is handling a command with the received ID and invokes the command on that target. Unfortunately, this mechanism is rather complex and difficult to master.
It would be helpful if there were an easy, flexible way to connect UI elements to the commands exposed on the application model. Moreover, it would be helpful if it were also possible to make the software development process easier for designers and developers.